Some x86 guest operating systems (OS) implement periodic timing as the means to create a software stepping signal to update their time of day counters. These operating systems use the programmable interrupt timer to interrupt or fire at a predictable rate and update the operating system counter that is used to keep track of elapsed time. Time for an operating system can be maintained by a kernel clock and the time-of-day clock. The time-of-day clock is derived from the kernel clock unless the time-of-day clock is externally modified, for example, by a user. If for example, the time-of-day clock is externally modified, the kernel clock will not track the time-of-day clock, but will remain unchanged. A virtualization service creates a virtual programmable interrupt timer, one or more for each virtual machine, and the virtual programmable interrupt timer relies on a regular, periodic host operating system callback mechanism to accurately emulate the programmable interrupt timer for the virtual machines.
When the real programmable interrupt timer hardware is virtualized, the software virtualization is not in control of certain aspects of its operating environment. For example, the virtualization service implementing the virtual programmable interrupt timer may be preempted by other host activity causing the virtual system to have non-deterministic timing behavior. The virtual machines may also be preempted either by host activity or by other virtual machines executing in the same physical system. Consequently, there may be periods of time when a virtual programmable interrupt timer interrupt presented to the virtual machine may be delayed past the next expected timer period and effectively merged with the next virtual programmable interrupt timer interrupt. If this occurs, the virtual programmable interrupt timer may appear to “lose time” with respect to the actual time as the interrupt arrival rate becomes less than nominal The amount of time loss in the virtual programmable interrupt timer can range from a few seconds every minute with a light processor load on the host to a majority of the time every minute with heavy processor loads on the host machine. The greater the loss, the more problems the virtual machine will face in operation.
Several methods have been used in the past to keep more accurate time in a virtual machine. For example, Microsoft Virtual PC implemented a method that involved a guest operating system component periodically requesting the current time from the host and subsequently setting the correct externally visible time in the guest operating system. The guest operating system was informed by the host how often and whether or not to apply time correction along with the threshold of time-drift which should have a trigger setting a time correction.
For many aspects of x86 time-keeping, the Virtual PC method was functional, however it did have several significant deficiencies. Several types of guest operating system programs such as domain controllers were intolerant to having the external time inside the guest operating system suddenly “jump” forward when time was corrected. The guest operating system's time would “jump” forward when the operating system time-synchronization component realized that several seconds had been “lost” and would tell the guest operating system to advance the time. Also, the issue with time appearing to drift and run slower in the guest operating system was not addressed by this method.
In another method, the host operating system determines the location of the “clock” updated by the programmable interrupt timer interrupt handler in the guest operating system to prevent drifting. This method required intimate knowledge of the “clock” location in the guest memory for a specific guest operating system. This method, therefore, had to use an added guest component to discover the “clock” location to enlighten the guest operating system of the clock position. The location of the “clock” in the guest memory was then transmitted to the host so that the clock was updated directly. This method was also deficient because it required multiple changes to be made to the guest operating system. Further, the “clock” position varied in the different operating systems requiring additional components to be created for each operating system. This method would be highly unpractical today where there is a plurality of operating systems, in contrast to the past when there were only a few operating systems.
In yet another method, a component of the guest operating system was modified to request the precise elapsed time from the virtual machine. This method allowed enlightened guest operating systems to maintain precise, correct time. This method, however, required guest x86 operating systems to either request the correct time from the host or have the guest “advertise” the memory location of its operating system “clock.” This method was deficient because it required additional code to inform the operating system of the location of the clock. Thus, this method, too, required modification of the guest operating system that would be unpractical today with the plurality of operating systems in use.
Moreover, a method was invented where the steering information from the guest operating system was communicated to the virtualization service. Specifically, the clock time inside the guest operating system was transmitted periodically to the virtualization service. This method allowed the virtual service to calculate the difference in clock time between the guest operating system and host operating system so that the clock could be updated. This method was also deficient because a small amount of time loss or drift remained even after correction by this method.
In view of the foregoing, there is a need to overcome the limitations, drawbacks, and deficiencies of the prior art.